Field
The technology of the present application relates generally to a wireless microphone, or other wireless input device, such as a mouse, keyboard, pen, touch screen, sensor, or the like that accesses a remotely hosted application, and more particularly, to wireless microphones or devices connectable directly to a network to interact with a remotely hosted application such that the wireless device provides input to or commands to the remotely hosted application that are subsequently displayable or operable on a client device, which is separate from the wireless microphone, and separately connected to the remotely hosted application.
Background
Microphones and computing devices have co-existed for many years in a variety of form factors. The microphones may be internal, as is the case with smartphones, tablets, and notebooks; or as a plug-in peripheral, as is the case with desktops and laptops; or wireless, with a plug-in receiver for the local computer. Applications that process the audio from the microphone have conventionally been co-resident with the microphones on the local computer. In each case, the microphones interact directly with the computing device to which it is connected.
A dictation/transcription application is one example of an application running on a computing device that may receive input from the microphones and output text for display in either a text file, an editable field in a database, a user interface, or the like. Until recently, this type of application required a tight coupling between the microphone operationally coupled to a local computing device and the dictation/transcription application resident on the same local computing device. This necessitated a thick, heavy, or fat client machine as it was required to have the processing capacity to process the audio from the microphone and process the speech-to-text engine necessary to convert the audio from the microphone into text.
With reference to FIG. 1, a conventional thick client computing device 100 (sometimes referred to simply as thick client 100 or computing device 100) is shown where an application 102 is running on the computing device 100 that is directly or locally coupled to an input 104, such as, for example, a microphone 106, mouse 108, or keyboard (where the keyboard is not specifically shown). Notice the input 104 could include a number of other devices such as for example, an optical pen, a touch screen, or the like as are generally known in the art. The conventional thick client 100 also has a monitor 110 that may display an interface or text document to accept and display the data input through the input 104 or a processed version of the data input through the input 104. As can be appreciated, the thick client 100 and the application 102 running on the thick client 100, which may provide a display 112 on the monitor 110, receives audio 114 from a user that is transmitted directly to the application 102 via the microphone 106. If the application 102 is, for example, a dictation application, the audio 114 could be converted by the application 102 running on the thick client 100 into text that would be displayed on display 112 in a Microsoft Word document or a text field. Thus, the user speaks into the microphone 106 that transmits the audio 114 to the thick client 100 via a cable or wireless network connection 116. The application 102 running on the thick client 100 receives the audio 114 and performs some operation and the results (optionally) are displayed on the display 112, which could be a computer screen or monitor, a print out, a sound out, or the like. In some instances, the results may be transmitted back over the wireless network connection 116 to be displayed on a display of the input 104 should the input 104 be equipment with a screen and processors for such display. Essentially, as is generally understood by the terminology of a thick client, the microphone, application, and various computer components are all co-resident in one computing environment regardless of how the peripherals, such as the microphone 106 and display 112 are connected to the computing device 100. The connections could include a direct, wired coupling or a local wireless protocol such as, for example, Bluetooth, Wi-Fi, a LAN, a WAN, a cellular network, a WLAN, other IEEE 802.xx networks, the Internet or the like.
The microphone 106 associated with thick client 100 may be a wired or wireless microphone. In both cases, the microphone 106 transmits data to the client device 100. The microphone 106 may be an application resident on a smartphone or the like that may include, for example, a Bluetooth or Wi-Fi connection to the client device having an installed copy of Dragon Dragon Naturally Speaking®. The application converts a smartphone to a wireless microphone that transmits audio to the local client device.
With the Internet, it wasn't long before applications were no longer necessarily running or resident on the local computing device. In the case of the above referenced exemplary dictation/transcription application, the speech-to-text conversion engine or application module may be resident on a remote computing device that hosts the application. Typically, the remote computing device is more computationally powerful than the local workstation or client station. This is commonly referred to as a client computing device. In such an exemplary system, the audio is received by a microphone that is operationally coupled to a client device. The client device directs, via conventional network connection protocols, to the hosted application that processes the audio to text using the speech-to-text conversion engine and returns the text to the networked client device. The client device typically has a display onto which the results of the application's processing is displayed. Still, as described above, the microphone, whether wired or wireless, is tightly coupled to the client device, which may now be a thin client as the application is remotely hosted by a more powerful processor.
With reference to FIG. 2, a hosted or server application 202 is resident on a server 204 that may be remote from the client device 200 (sometimes referred to generically as client 200). The hosted application 202 and server 204 is visually depicted as in the cloud 201 as is generally understood in the art. In some applications, the architecture of FIG. 2 may be considered a thin client architecture. Thin client, in this context, means the user interacts with an application on a first computing device (client device 200 here) and a second computing device (server 204), typically remote from the first computing device performs some or a majority of the processing. Further, FIG. 2 shows the hosted application 202 as a Software as a Service application (or “SaaS”). SaaS is simply one common exemplary type of hosted application. The client device 200 receives data from an input 104 similar to the above that is operatively coupled to the client device 200, which is a thin client device in this exemplary embodiment but could be a fat client device. The client device 200 typically includes the monitor 110 that may project a display on the display 112 of the monitor 110. The data returned from the server application 202 may be a text document, in the case of certain types of dictation/transcription applications, or input to a graphical user interface displayed on the display 112, a result based on data entered into the graphical user interface, or the like. As can be appreciated, the change in relationship between the components of FIGS. 1 and 2 happens with network based applications, where the network based application is private or public. In a public environment, such applications may be referred to as Software as a Service or “SaaS” as mentioned above. Generally, SaaS is split into two pieces, a heavy-weight hosted application 202 running on a server 204 in a remote data center, and a light-weight client application 206 running on the client device 200 (while shown for convenience on the monitor 110) the client application 206 would be operating to cause the processor 203 of the thin client 200 to execute instructions. In our exemplary embodiment, where the hosted application 202 is a speech-to-text engine, the user speaks into the microphone 106 that is operatively connected to the client application 206 running on the client device 200. The client application 206 directs the audio to the hosted application 204 that processes the user's audio and sends instructions and data to the client application 206. Similarly to the above, the peripherals to the client device 200 may be connected to the client device 200 by cable, Bluetooth, or Wi-Fi. Distributed transcription systems are further described by, for example, U.S. Pat. No. 8,150,689, titled Distributed Dictation/Transcription System, which issued Apr. 3, 2012, and U.S. Pat. No. 8,311,822, titled Method and System of Enabling Intelligent and Lightweight Speech to Text Transcription Through Distributed Environment, which issued Nov. 13, 2012, both of which are incorporated herein as if set out in full.
The microphone 106 associated with thick client 100 or client 200 may be a wired or wireless microphone. In both cases, the microphone 106 transmits data to the local client device 100, 200. The microphone 106 may include, for example, a Bluetooth or Wi-Fi connection to the client device. One such application includes the Dragon Remote Microphone Application that interfaces through a networking protocol with a client device having an installed copy of Dragon Naturally Speaking®. The application converts a smartphone to a wireless microphone that transmits audio to the local client device. Another application that is downloadable to a smartphone is Philips dictation recorder available from Koninklijke Philips N.V. The Philips dictation recorder, however, is different from the Dragon Remote Microphone Application in that it is usable as a conventional Digital Audio Recorder. At the end of which, the audio file is transmitted by the client device 200 to a server application for batch transcription. The transcription is emailed once finished back to the user.
For remotely hosted engines processing the speech to text, the audio is processed by the server executing the hosted application. Therefore the audio has to be sent from the client device to the server, often over a public network, such as the Internet. Sometimes this is a problematic. In one aspect, the audio rebroadcast by the client device to the server executing the hosted application may be of inferior quality due to the retransmission. For example, when the bandwidth from the client device to the server is poor, the connection interferes with the delivery of the audio to the server. In another example, the audio may be received by the client device, but the client device cannot deliver the audio to the server for processing. Another potential problem in this deployment scenario occurs when the user is in a secure environment, such as a hospital, which only grants Wi-Fi access to registered devices, which may preclude the microphone 106 from establishing a direct connection needed to the client device 200. These are but some examples of potential problems associated with using a wireless microphone with the architecture in FIG. 2.
The conventional thick client and client applications where audio is used as an input are problematic in view of some of the issues above. There may be added difficulty in that the ability of the application to function often depends on the quality of the audio input received. Often, the thick client or client device 100 or 200 is delivered with a built in microphone 106. The results of using a built in microphone 106 are typically poor because audio fidelity was not the primary factor considered when sourcing the microphone . The quality of built in microphones has traditionally been a low priority for device manufacturers. Device manufacturers often choose a microphone component based primarily on its low cost and require only that the microphone be able to function at minimally acceptable levels for miscellaneous use. Because the quality of the device's microphone has traditionally been a low priority for consumers, device manufacturers prefer to save money on the microphone and put that money into component(s) more highly valued by consumers, such as display size or quality, or speaker clarity or loudness. Thus, users of applications that receive audio often grow frustrated with the results of the applications because the application (or applications) does not appear to work properly. However, in these situations, it may be the microphone that is causing the problems in operation without the knowledge of the user. Sometimes the thick client or client device is not provided with a built in microphone. The user is required to purchase a microphone separately when one is not built into the computing device. The user typically does not know how to select a suitable microphone for the intended use and is likely to purchase one which yields poor results. Moreover, quality microphones that enhance the audio quality are sometime expensive, and may be prohibitively expensive in certain situations. Therefore, the user encounters a similar problem in that quality of the audio is poor and the associated applications do not function properly. However, many users in fact already own a microphone with sufficient audio fidelity to achieve good results with the applications. This microphone is in their smartphone, such as an iPhone 5S. The audio transmission from the smartphone microphone may be of sufficient audio quality, but the retransmission from the client device to the server executing the host application compromise the quality of the audio. However, users do not have an easy way to connect the microphone from the smartphone directly to the server executing the hosted application such that the server transmits the results to the client's workstation, separate from returning the results directly to the smartphone.
Moreover, the above referenced smartphone applications while useful, are less than satisfactory solutions to providing a good, wireless microphones for the architectures described in FIGS. 1 and 2 above. In particular, the smartphone wireless microphone applications use a Wi-Fi connection the client device. It is difficult, at best, to successfully network the smartphone wireless to the client application on the client device.
Thus, against this background, it is desirable to provide an improved wireless microphone to provide audio input to remotely hosted applications and in particular to be able to use a smartphone's built-in microphone for a separate client workstation or device receiving the results of the remotely hosted applications.